









writing up a contract also forces the user to 
properly prepare for the project. You’ll be 
ready with a list of logicsd, specific demands. 
You’ll have a clear description of everything 
you want. 

Cohtract checklist 

The scope of the project. This is the most 
important clause and the one most users fail to 
write properly. Don’t settle for naming the ap¬ 
plications and a few general features. Describe 
carefully eve^ feature you want and include . 
sample output reports. 

}/• The timetable. 'The major events — the 
design, the coding, the testing — should appear 
in the contract with deadlines. Include remed¬ 
ies and rights if the deadlines are not met. 

✓ Payment schedule. Schedule payments to 
performance. Your payments are your only 
real leverage to guarantee that each step is 
done to your satisfaction. Link all payments to 
the completion of a task. Retain at least a third 
of the total bill until the system has been fully 
operational for a given period of time. 

✓ Who owns the product. Serious misunder¬ 
standings can arise if this clause isn’t crystal 
clear. Without agreement to the contrary, the 
copyright laws can be construed to give the pro¬ 
grammer ownership of the code. Be sure to 
clarify whether the programmer has the right 
to sell the programs to others. 

I/' Trade secrets. In the course of the 
project, the programmer may have access to 
customer lists, payroll data or other valuable 
information. Spell out that all such data re¬ 
mains your sole property and mention penalties 
if security is breached. 

I/' Programmer is an independent contrac¬ 
tor. Failure to clearly establish this can result 
in problems with the IRS. Also, in case of a 
dilute, you don’t want the pro^ammer claim¬ 
ing to be an employee and cashing in on work¬ 
er’s compensation, unemployment benefits, etc. 

x/' Legal responsibility. Be sure that the pro¬ 
grammer accepts all legal and financial re^on- 
sibilities for anyone else he or she employs. 
I^of of bonds and errors and omissions (E&O) 
insurance should be required. 

1 ^ Right to terminate agreement. Be sure to 
define at least two options to terminate — the 
first at the end of each phase or milestone. If, 
for example, the programmer delivers an inad¬ 
equate design, you should have the option to 
terminate without further obligation. Second, 
you should build in the option to terminate with¬ 
out cause. Your financial position may take a 
turn for the worse, or you may simply want to 
cut yourself loose from a project that is hope¬ 
lessly bogged down. Obviously, you would pay 
the programmer for efforts to that point. 

Final precaution 

Last, but not least, I always recommend that 
programming contracts contain bn arbitration 
clause. This may provide you with the only 
practical means of enforcing the agreement. 
Litigation is generally too time-consuming and 
cosUy to be much help. But if both parties 
agree in advance to submit disputes to binding 
arbitration, you stand a better chance of solv¬ 
ing major problems quickly. 
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